Internet Info 1994 March/Internet Info CD-ROM (Walnut Creek) (March 1994).iso/inet/ietf/acct/acct-minutes-90feb.txt

Text File | 1993-02-17 | 11.3 KB | 263 lines

CURRENT_MEETING_REPORT_


Reported by Cyndi Mills/BBN

AGENDA


   o Bounding the Charter.
   o Form a Working Group
   o Requirements Discussion:  Draft Minutes below.


Minutes


  1. Summary
     Agreed to form an Internet Accounting working group.  Cyndi Mills
     will chair it and write the charter.  This working group is in the
     Network Management Area under Dave Crocker.
  2. Bounding the Charter:
     We need to examine a wide range of policies to understand what set
     of information is required to satisfy the billing and reporting
     requirements, bearing in mind realistic requirements and
     restrictions regarding:
       o Availability of Information,
       o Performance, and
       o Accuracy.
     Policy Disclaimer:  Neither issues surrounding how policies are set
     nor how they are formulated will be addressed by this group.
     2.1 OSI Accounting
     Brian Handspicker, ANSI X3T5.4 OSI Management Accounting Ad Hoc
     Group Leader, presented the OSI view of accounting.  The OSI
     Accounting working group is defining the collection service and
     protocols.  The OSI group is not addressing the content information
     to be measured and reported by the collection service.  Suggest
     that the IETF working group coordinate with the OSI accounting
     group so as not to duplicate effort.
     Meter <--> Collector <--> Application
     Application:  The application manipulates the billing data in
     accordance with policy, and determines which information will be
     requested from the metering devices.
     Collector:  The collector is responsible for integrity and security
     of the data during transport from the meter to the application.
     Meters:  Meters perform the measurement and aggregate the results.
     The characteristics of the meter may be implementation-specific.
     2.2 Data Generation vs.  Data Collection vs.  Billing Application
     The generation of accounting data (the meter function) is the focus
     of this IETF group.  First, we need to determine what information
     will satisfy the widest possible range of policies, and what the
     constraints are.  Secondly, we should cover local storage and
     aggregation techniques.

                                   1






   Data collection protocols, i.e.  methods for carrying accounting
   data, are under development in ANSI. Accounting data may be carried
   by a combination of protocols, including network management
   protocols such as OSI Accounting, SNMP, CMIP. The selection of
   collection protocol(s) should be deferred until the structure and
   constraints of the carried data are known.
   The billing process, i.e.  the processing of the accounting data,
   is beyond the scope of this group.  Billing methods, tariffs, and
   exceptions tend to be unique to each organization.
   2.3 Network-Level vs.  Host-Level
   The information available to the meter depends on its location in
   the network.  One of the major issues here is attribution - with
   what granularity can we account for the source and destination of
   network traffic?  Can we track the source/destination of a packet
   to the autonomous network, the network number, the host address,
   the user, or to a charge number on one of a user's many projects?
   For network meters, a function attached to the routers, this
   information is limited to what can be extracted from the IP packet
   flow.  Various counters may be implemented, but attribution of the
   packet to a source is limited to the information available in the
   IP address (and the protocol ID of the protocol carried).  There is
   no unique identifier in the packet for a user.
   Host meters are more flexible.  They have direct knowledge of the
   user and his operation, and are in a position to implement
   user-level accounting in accordance with the behavior of a specific
   operating system.
   This working group will concentrate on network-level meters.  The
   discussion section covers a number of background arguments for this
   restriction.
3. Discussion
   The Internet community is made up of:
     o Network providers, e.g.  backbone and regional networks, who
       usually own the transmission media, regulate or own the
       routers, but disown the hosts.  Internet accounting is for the
       benefit of the network provider, an aid in the implementation
       of the network provider's policy.  In networks with chargeback
       policies, accounting may be the sole source of funding for the
       network.
     o Network users, e.g.  hosts, individual users, and projects.
       These are the consumers of network services.  From an
       accounting point of view, these are the end-users, the finest
       granularity of attribution.
     o Stuck in the middle.  These are the entities that are both
       providers and consumers of network services.  Hosts and
       regional networks are frequently in this category.  They
       receive service from the network and provide network service to
       the user.  In addition to compensating other network providers
       for network services rendered, they must assist in allocating
       responsibility for those services received and provided to
       end-users.
   The phone company analogy was used frequently to illustrate several
   interrelated points.

     o Regional/Local Operating Providers:  The Bell Operating

                                 2






         Companies (BOCs) serve as the network connection point for
         subscribers.  They maintain directories and connectivity
         information, because they control the end-users' connections.
       o Long-Distance Providers:  AT&T and MCI are backbone services.
       o PBX Installations:  A subscriber may be a single telephone, or
         a private telephone network.  The private telephone network is
         analogous to the LAN: it receives a bulk bill from the regional
         BOC and it is responsible for maintaining its own records to
         allocate costs back to its local users.


The potential billing models between a long-distance provider and a
middleman (BOC) provider in the phone company model illustrated some of
the issues.

Under the existing policy, the BOCs bill users for long-distance
services as a courtesy to the long- distance companies, who set the
rates.  Two hypothetical models for implementing this service were
discussed.

The long-distance company provides per-call detail to the BOC. The BOC
maintains the accounting data and the association of usage data with its
end-users.  The BOC generates the bill.

The BOC provides per-call "tags" to identify its end users to the
long-distance provider.  The long- distance carrier maintains the
accounting data and the association of usage data with those tags.  The
long- distance carrier generates the bills' contents.  The BOC simply
forwards the bill to the user associated with its "tags".

Under a hypothetical policy, BOCs receive an aggregate bill for
long-distance services from the backbone provider.  The BOC is treated
as a single billable entity by the long-distance service.  In this case,
the BOC is solely responsible for maintaining the accounting data and
policies which allocate those costs to users.  The BOC provides no
user-level information to the backbone provider, nor does the backbone
provider give detailed per-call accounting to the BOC. (Not
interactively, at least.)

DEFINE THE BILLABLE ENTITY FIRST. We are examining the nature of
traffic, interesting but too much for simple accounting purposes.  Start
with the definition of the "billable entity" and build up to what you
need.

DON'T INCLUDE NETWORK DESIGN AND ANALYSIS DATA. Accounting needs very
precise data about certain kinds of traffic.  Network design and
analysis needs different data, and frequently works with sampling
techniques inappropriate for accounting.  Although much of the
accounting information may be useful for network design and analysis,
covering network design and analysis requirements will overburden the
scope of this group.


                                   3






NEED TO KEEP THE ENTITY MATRIX SIMPLE. There are inherent limits in the
current situation.  Routers can't handle keeping a matrix of counters
for every possible user-user combination.  Some kind of hierarchical
billing is required.  One division is for hosts to be billed in
aggregate by the network, and leave the hosts responsible for allocating
costs to users.  However even host-host matrices can get very large.  If
each datagram entering a router is on a different source- destination
pair, thrashing could be easily induced.

WATCH OUT FOR OVERHEAD. Accounting for every packet in a fine- grain way
could result in 100may have more than 50it can be appropriately
attributed to users.  50off point for feasibility.

DIFFERENT ALGORITHMS FOR LOCAL AND LONG-DISTANCE SERVICES: Note that the
phone company uses different algorithms for local and long distance
services.  Long distance calls are handled with detailed call accounting
or aggregate counts (message units).  Local calls are handled with
simple aggregate counts (message units) or flat fees regardless of
usage.

The lesson here is that where the cost of accounting is huge in
comparison with the cost of providing the basic service, many
subscribers prefer a policy which allocates usage as a flat fee.  Some
subscribers, however, (message units), still want usage-based fees.
Phone companies provide a wide variety of such combinations of service.

WHAT ABOUT SPECIAL END-USERS? Suppose I am a long-distance carrier and I
want a particular research group to get a special rate.  In the various
models how can I ensure that their traffic and only their traffic is
billed at the reduced rate?  How do government clients get a bulk rate?

We need to consider the interaction between government and commercial
entities, e.g., what does GEC Marconi do when it wants to communicate
with NASA on commercial issues?

NEED A SET OF TEST QUESTIONS FOR PRELIMINARY VERIFICATION OF THE MODEL.
What is an accountable unit?  Examples of questions that should be
answered are how to deal with rate periods (time-of-day), special
end-users, etc.  Need many more questions.

ON FORMING A WORKING GROUP: We will see commercial services in the
Internet.  This will require accounting.  The IETF should get the
process set up first.  Good value for traffic and capacity planning, as
well.  Suggest we talk to people who are planning to offer commercial
Internet service (PSI, UUNET, Finnish PTT, SMDS) to see what kinds of
charging strategies they use.  The RACE program, with Ira Richer, is
also working on accounting issues.


ATTENDEES

    Cerf, Vinton               [e-mail]

                                   4






Crocker, Dave              [e-mail]
Crocker, Steve             [e-mail]
Fernandez, Louis           [e-mail]
Handspicker, Brian D.      [e-mail]
Kirstein, Peter            [e-mail]
Lazear, Walter             [e-mail]
Little, Mike               [e-mail]
Morris, Dennis             [e-mail]
Newkerk, Oscar             [e-mail]
Pace, Donald               [e-mail]
Saperia, Jon               [e-mail]
Su, Zaw-Sing               [e-mail]
Youssef, Mary              [e-mail]
Yuan, Aileen               [e-mail]



                               5